Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

config: Add consoleSize to process #563

Merged
merged 1 commit into from
Sep 21, 2016

Conversation

lowenna
Copy link
Contributor

@lowenna lowenna commented Sep 14, 2016

Signed-off-by: John Howard jhoward@microsoft.com

Extracting pieces from the proof of concept PR for Windows OCI support at #504. This adds the consoleSize platform specific field to the Process structure.

@@ -118,6 +118,10 @@ For more information about SELinux, see [Selinux documentation](http://selinuxp
* **`noNewPrivileges`** (bool, optional) setting `noNewPrivileges` to true prevents the processes in the container from gaining additional privileges.
[The kernel doc](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt) has more information on how this is achieved using a prctl system call.

For Windows-based systems, the process structure supports the following process specific fields:

* **`initialconsolesize`** (array of ints, optional) specifies the initial console size (height, width) of the terminal if attached.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

capitalization is significant

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I deliberately did this as the capitalisation is consistent with other items such as rlimits (vs rLimits). Are those incorrect as well? If so, I'll open another PR to address that, but fix the capitalisation to initialConsoleSize here.

@wking
Copy link
Contributor

wking commented Sep 14, 2016

On Wed, Sep 14, 2016 at 01:38:46PM -0700, John Howard wrote:

Yes, I deliberately did this as the capitalisation is consistent
with other items such as rlimits (vs rLimits). Are those
incorrect as well? If so, I'll open another PR to address that, but
fix the capitalisation to initialConsoleSize here.

Touche ;). I'm fine with rlimits, rLimits, and resourceLimits. And
consistency is nice, but there's also a benefit to using the
platform's conventional casing [1]. I'm fine letting per-patform
maintainers go their own way on this sort of style decision.

@lowenna
Copy link
Contributor Author

lowenna commented Sep 14, 2016

Updated it to camelCase. Given there's almost no Windows specific fields in the spec currently, I may as well start with a sensible pattern.

@tianon
Copy link
Member

tianon commented Sep 15, 2016

LGTM

Approved with PullApprove

@@ -51,6 +51,8 @@ type Process struct {
ApparmorProfile string `json:"apparmorProfile,omitempty" platform:"linux"`
// SelinuxLabel specifies the selinux context that the container process is run as. (this field is platform dependent)
SelinuxLabel string `json:"selinuxLabel,omitempty" platform:"linux"`
// InitialConsoleSize contains the initial h,w of the console size. (this field is platform dependent)
InitialConsoleSize [2]int `json:"initialConsoleSize" platform:"windows"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

uint? ;)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup. Good catch. Updating - pushing shortly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. And the matching doc change ;)

@@ -51,6 +51,8 @@ type Process struct {
ApparmorProfile string `json:"apparmorProfile,omitempty" platform:"linux"`
// SelinuxLabel specifies the selinux context that the container process is run as. (this field is platform dependent)
SelinuxLabel string `json:"selinuxLabel,omitempty" platform:"linux"`
// InitialConsoleSize contains the initial h,w of the console size. (this field is platform dependent)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Drop “this field is platform dependent” (#568, #569).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, of course :)

@tianon
Copy link
Member

tianon commented Sep 15, 2016

LGTM redux

Approved with PullApprove

@wking
Copy link
Contributor

wking commented Sep 15, 2016 via email

@anuthan
Copy link
Contributor

anuthan commented Sep 15, 2016

LGTM

@lowenna
Copy link
Contributor Author

lowenna commented Sep 15, 2016

Grammer police 🚔 😄 @wking - Fixed, thanks for catching.

@wking
Copy link
Contributor

wking commented Sep 15, 2016

On Thu, Sep 15, 2016 at 10:29:25AM -0700, John Howard wrote:

Grammer police 🚔 😄 @wking - Fixed, thanks for catching.

2a7b7c6 looks even better to me ;).

@@ -118,6 +118,10 @@ For more information about SELinux, see [Selinux documentation](http://selinuxp
* **`noNewPrivileges`** (bool, optional) setting `noNewPrivileges` to true prevents the processes in the container from gaining additional privileges.
[The kernel doc](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt) has more information on how this is achieved using a prctl system call.

For Windows-based systems, the process structure supports the following process specific fields:

* **`initialConsoleSize`** (array of uints, optional) specifies the initial console size (height, width) of the terminal if attached.
Copy link
Member

@tianon tianon Sep 15, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just realized this is (height, width) -- isn't it more common for these particular types of values to be ordered (width, height)? Is this ordered this way arbitrarily, or is this how the underlying platform support orders them?

For example:

image

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ordering here is consistent with the way the platform API is implemented.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 thanks for confirming ❤️

@tianon
Copy link
Member

tianon commented Sep 15, 2016

LGTM redux

Approved with PullApprove

@@ -118,6 +118,10 @@ For more information about SELinux, see [Selinux documentation](http://selinuxp
* **`noNewPrivileges`** (bool, optional) setting `noNewPrivileges` to true prevents the processes in the container from gaining additional privileges.
[The kernel doc](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt) has more information on how this is achieved using a prctl system call.

For Windows-based systems, the process structure supports the following process specific fields:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is also needed in the linux.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@laijs Why do you think that? It's needed on Windows to init the conhost terminal, but it's only ever been in Windows to date.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In linux, we also use a default winsize for the tty console when starting the container, and then we resize it later, these is a gap between them.

@lowenna
Copy link
Contributor Author

lowenna commented Sep 17, 2016

Updated to not make this a Windows-specific field after comment https://github.com/opencontainers/runtime-spec/pull/563/files#r79284892 from @laijs

@@ -31,6 +31,8 @@ type Spec struct {
type Process struct {
// Terminal creates an interactive terminal for the container.
Terminal bool `json:"terminal,omitempty"`
// InitialConsoleSize contains the initial h,w of the console.
InitialConsoleSize [2]uint `json:"initialConsoleSize"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello, @maintainers, how about use a more verbose structure here?

type ConsoleWindowSize struct {
    Height uint `json:"height"`
    Width  uint `json:"width"`
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 for explicit height/width. Although probably no need for the specific name. type Box would give us something we could use in other places, although I can't think of other consumers now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 for this change, @jhowardmsft WDYT?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. Updated using Box, and updated the docs accordingly

@lowenna
Copy link
Contributor Author

lowenna commented Sep 18, 2016

@wking @laijs @hqhq Updated.

@@ -95,6 +95,7 @@ See links for details about [mountvol](http://ss64.com/nt/mountvol.html) and [Se
**`process`** (object, required) configures the container process.

* **`terminal`** (bool, optional) specifies whether you want a terminal attached to that process, defaults to false.
* **`initialConsoleSize`** (box, optional) specifies the initial console size of the terminal if attached.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer naming as consoleWindowSize as @laijs suggested, because we might want to update process console size and it seems weird to assign new config to the field with initial prefixed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hqhq - @laijs explicitly said this was needed on Linux, so I don't understand your comment? As for initial, this is important - it's the how the console is initialised for the console start, so I don't agree with your other suggestion.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes Linux has tty console size, but the Window in the name consoleWindowSize doesn't mean Windows operate system, it just reflect semantics from http://man7.org/linux/man-pages/man4/tty_ioctl.4.html (section Get and set window size).

And I don't think we need to specify initial for the usage of initialization, otherwise we'll call InitialArgs, InitialRlimits, etc.. Not to mention that they can also be used in non-initialization stages.

@wking
Copy link
Contributor

wking commented Sep 18, 2016

On Sat, Sep 17, 2016 at 11:24:02PM -0700, Qiang Huang wrote:

Not to mention that they can also be used in non-initialization
stages.

I'm fine dropping initial, but thought I'd point out that the current
spec is not supporter of join-and-tweak. See the in-flight #540
trying to clarify that position, and the open #305 in favor of
allowing join-and-tweak. I'm personally in favor of allowing
join-and-tweak, but filed #540 because I'd rather have clearer wording
on the no-tweaking restriction while we want for the consensus to
shift towards allowing join-and-tweak.

@hqhq
Copy link
Contributor

hqhq commented Sep 18, 2016

@wking Yeah I plan to put this back on table post-1.0, but we'll support it in runc whether it's in spec or not, so we better keep it looks reasonable for update.

@lowenna
Copy link
Contributor Author

lowenna commented Sep 18, 2016

Are there not already many fields which are not configurable post create? I don't care though, if consensus is to remove 'initial', so be it. Imo it seems pretty descriptive of the purpose though.

@wking
Copy link
Contributor

wking commented Sep 18, 2016

On Sun, Sep 18, 2016 at 12:34:59AM -0700, John Howard wrote:

Are there not already many fields which are not configurable post
create?

It may be helpful to think about this in three classes:

a. Initial setup. The resource (e.g. a console) was just created and
needs to be configured. That's what most/all of the current config
settings are about.
b. Out-of-band tweaking. Users can do whatever they want outside of
the runtime, e.g. dragging their console around to resize it.
c. Runtime tweaking. A subsequent runtime invocation updates an
existing resource. This is what #305 and #540 are talking about.

It's probably good to remind users that most settings are not set in
stone, and that (b) and maybe eventually (c) are possible (one example
where this isn't true is the user map 1, which is “write once and
you're stuck with it” 2). But I don't think prefixing properties
with “initial” is the most efficient way to remind them.

 > An attempt to write more than once to a uid_map file in a user
 > namespace fails with the error EPERM.  Similar rules apply for
 > gid_map files.

@lowenna
Copy link
Contributor Author

lowenna commented Sep 19, 2016

@wking. Thanks. The current commit f2bc43b should reflect the changes based on all feedback to date.

I would be inclined to say that adding something like opencontainers/image-spec#311 belongs in a separate PR rather than polluting this one. I'm happy to put that together later today.

@wking
Copy link
Contributor

wking commented Sep 19, 2016

On Mon, Sep 19, 2016 at 11:02:46AM -0700, John Howard wrote:

I would be inclined to say that adding something like
opencontainers/image-spec#311 belongs in a
separate PR rather than polluting this one. I'm happy to put that
together later today.

That's fine with me. Leaving the consoleSize-unset behavior implicit
for an afternoon is fine. And perhaps the
opencontainers/image-spec#311 port lands first, in which case we can
reroll this to explicitly make the consoleSize-unset case unspecified.

f2bc43b looks good to me, except the commit summary should now be:

config: Add consoleSize to process

@lowenna lowenna changed the title Windows: Add consoleSize to process config: Add consoleSize to process Sep 19, 2016
@lowenna
Copy link
Contributor Author

lowenna commented Sep 19, 2016

Ah yes, of course. Commit summary and PR title updated.

@wking
Copy link
Contributor

wking commented Sep 19, 2016 via email

@hqhq
Copy link
Contributor

hqhq commented Sep 20, 2016

LGTM

Approved with PullApprove

@lowenna
Copy link
Contributor Author

lowenna commented Sep 20, 2016

@tianon - sorry, it's gone through a few revisions since your last LGTMs. Any chance of a further review? Thanks ❤️

@mrunalp
Copy link
Contributor

mrunalp commented Sep 20, 2016

LGTM

Approved with PullApprove

@tianon
Copy link
Member

tianon commented Sep 20, 2016

Nice, I like the introduction of the box type to avoid having to just "know" what order the arguments go in. 👍

LGTM
(although appears to now have a conflict in config.md)

Approved with PullApprove

@wking
Copy link
Contributor

wking commented Sep 20, 2016

On Tue, Sep 20, 2016 at 02:27:34PM -0700, Tianon Gravi wrote:

(although appears to now have a conflict in config.md)

#574 is probably causing a lot of trivial conflicts.

@lowenna
Copy link
Contributor Author

lowenna commented Sep 20, 2016

Rebased. Yes, it was #574 (optional --> OPTIONAL)

@@ -95,6 +95,7 @@ See links for details about [mountvol](http://ss64.com/nt/mountvol.html) and [Se
**`process`** (object, REQUIRED) configures the container process.

* **`terminal`** (bool, OPTIONAL) specifies whether you want a terminal attached to that process, defaults to false.
* **`consoleSize`** (box, OPTIONAL) specifies the console size of the terminal if attached.
Copy link
Contributor

@wking wking Sep 20, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's pretty clear from the Go and JSON Schema what “box” means here. But it's the Markdown that's normative. I'd recommend either inlining the defintion here:

  • consoleSize (object, OPTIONAL) specifies the console size of the terminal if attached.
    Contains the following properties:
    • height (uint, REQUIRED) specifies the height of the console.
    • width (uint, REQUIRED) specifies the width of the console.

Or defining box in a separate section at the end of this file:

Box

A geometric box.
This object has the following fields:

  • height

Copy link
Contributor Author

@lowenna lowenna Sep 20, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated using the first notation from your suggestions. (a502caf)

Signed-off-by: John Howard <jhoward@microsoft.com>
@wking
Copy link
Contributor

wking commented Sep 20, 2016 via email

@hqhq
Copy link
Contributor

hqhq commented Sep 21, 2016

LGTM

Approved with PullApprove

1 similar comment
@mrunalp
Copy link
Contributor

mrunalp commented Sep 21, 2016

LGTM

Approved with PullApprove

@mrunalp mrunalp merged commit c356a80 into opencontainers:master Sep 21, 2016
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request May 26, 2017
…r unset

The old language is from a502caf (config: Add consoleSize to process,
2016-09-14, opencontainers#563), where nobody commented on the "if attached" wording
[1].  But reading the old line now, it's not clear to me what
consoleSize means when terminal is not true.

This commit explicitly declares consoleSize unspecified in that
condition, so runtimes are free to do what they want short of erroring
out.  I considered making the property undefined or requiring it to be
unset, but those seemed too strict given our permissive "MUST ignore
unknown properties" extensibility requirement.

[1]: opencontainers#563

Signed-off-by: W. Trevor King <wking@tremily.us>
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request Jun 1, 2017
…r unset

The old language is from a502caf (config: Add consoleSize to process,
2016-09-14, opencontainers#563), where nobody commented on the "if attached" wording
[1].  But reading the old line now, it's not clear to me what
consoleSize means when terminal is not true.

This commit explicitly declares consoleSize unspecified in that
condition, so runtimes are free to do what they want short of erroring
out.  I considered making the property undefined or requiring it to be
unset, but those seemed too strict given our permissive "MUST ignore
unknown properties" extensibility requirement.

[1]: opencontainers#563

Signed-off-by: W. Trevor King <wking@tremily.us>
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request Jun 1, 2017
…r unset

The old language is from a502caf (config: Add consoleSize to process,
2016-09-14, opencontainers#563), where nobody commented on the "if attached" wording
[1].  But reading the old line now, it's not clear to me what
consoleSize means when terminal is not true.

This commit explicitly declares consoleSize ignored in that condition.
I'd rather have made it unspecified, so runtimes are free to do what
they want short of erroring out, but Michael wanted the more specific
"ignored" [2].  I considered making the property undefined or
requiring it to be unset, but those seemed too strict given our
permissive "MUST ignore unknown properties" extensibility requirement.

[1]: opencontainers#563
[2]: opencontainers#863 (comment)

Signed-off-by: W. Trevor King <wking@tremily.us>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants